iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 3
0
自我挑戰組

來讀設計模式:Junior developer 跟大家一起練功系列 第 9

DAY9: 共通性與可變性分析;敏捷程式設計

  • 分享至 

  • xImage
  •  

本篇接著談論 Chapter 8 的後半部分,我將談到兩個主題:

  • 共通性與可變性分析
  • 敏捷開發與設計模式

今天的內容會比較輕鬆,偏概念性。Here we go!

共通性&可變性分析

簡言之,如何在不同領域中找到共同點:找到變化的地點,稱為共通性分析

根據 Jim Coplien 的說法:

共通性分析就是尋找一些共同的元素,他們能夠幫助我們理解系列成員的共同之處在哪裡。

舉例來說,一隻鴨子、一隻袋鼠、一個人類,它們的共同點就是它們都是「用兩腳行走的動物」。有了共通性分析,我們就能更容易討論做為用兩腳行走的動物,它們有拿些差異。

找出如何變化,稱為可變性分析。而可變性只有在指定共通性之後才有意義:

共通性分析尋找的是不可能隨時間而改變的結構,而可變性則是要找到可能變化的結構。

從架構的視角來看,共通性分析為架構提供長效的要素,而可變性分析則促進它適應實際使用所需。

加上軟體設計的三種視角

如果我們把軟體設計的三種視角加入上述的思考,我們會得到下圖(還原得很醜):

共通性分析與概念視角相互關聯;可變性分析與實作視角相互關聯。

規約視角夾在中間與另外兩種視角互動:

  • 與概念視角的關係:標記出用來處理此概念所有情況所需的介面
  • 與實作視角的關係:在指定的規約下如何實作
定義⋯⋯時 必須問自己⋯⋯
抽象類別(共通性) 需要用什麼介面來處理這個類別的所有責任
衍生類別(可變性) 對於這個指定的特定實作,應該如何根據指定的規約來實作它

敏捷程式設計與設計模式

接下來我們來討論敏捷程式設計

簡單敘述敏捷程式設計

敏捷程式設計遵循著「一邊開發一邊設計」,在程式設計的同時進行驗證。

與設計模式是否矛盾

設計模式常常被描述為需要「預先設計再做開發」,看起來與敏捷程式開發是矛盾的。

但本書作者認為,它們的目標是相同的:敏捷開發企圖讓程式碼更具有可變性;設計模式要的是能產生更靈活的程式碼。

兩者都關心的程式品質

而且,敏捷程式設計與設計模式都關心高品質的程式碼。這些品質有:無冗餘可讀可測試

無冗餘

無冗餘簡言之:某個規則只要在一個地方實作。這就是我們先前提過的 DRY (Don't Repeat Yourself) 原則;Kent Beck 稱之為 OOAO (One and Only Once) 原則。

冗餘與耦合之間關係緊密:如果存在冗餘,那麼當修改其中一部分時,極有可能另一部分也是需要修改的。因此,兩部分的程式碼是相互耦合的。

「依介面設計」的做法 —— 找出變化並且封裝,使程式碼高內聚 —— 正式消除冗餘需要的。

所以,良好地運用設計模式也能避免冗餘發生。

可讀性高

依照極限程式設計宣導者 Ron Jeffries 所說,能夠產生好讀的程式碼,需要「依企圖做程式設計」,因為在閱讀程式時,我們往往是看程式碼的意圖,而不是細節的實作。

而依企圖做程式設計在此又與設計模式的「依介面設計」的原則類似,都是在不考慮實作的情況下先建立介面。

可測試性高

可測試的程式碼是敏捷開發的核心。可測試性也與其他實踐密切相關:

  • 高內聚的程式碼更容易測試,因為程式碼只負責一項責任
  • 鬆耦合的程式碼比緊耦合更容易測試
  • 冗餘程式碼雖然不會增加測試的難度,但有可能會降低覆蓋率,讓整個系統的可測性降低
  • 可讀性高的程式碼較容易被測試,因為函數或參數名稱都能精確描述它們的意圖
  • 封裝性好的程式碼容易測試,因為它與其他程式碼的耦合性低

接下來

Chapter 8 到這裡告一個段落。下一篇將介紹另一個設計模式:Strategy 模式。明天見!


上一篇
DAY8: 用不同觀點看物件與封裝
下一篇
DAY10: Strategy 模式1
系列文
來讀設計模式:Junior developer 跟大家一起練功22
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言